1. Field of the Invention
The present invention relates to an arrangement for controlling data packet flow in a communication system supporting communication of packet data, e.g. within a packet based network in general or between external packet data networks and end users e.g. over a backbone/core network. The invention also relates to a traffic node, in a communication system supporting communication of packet data within the network or over a backbone/core network, with flow controlling capability. The invention also relates to a method of controlling data packet flow in a communication system supporting communication of packet data, within an IP-network or particularly from external packet data networks towards end users over a backbone or core network.
2. Description of the Related Art
Traditionally, or so far, real-time communication service has generally been handled within the 2G telecommunication environment. Many applications designed in the 2G telecommunication environment have been implemented with a proprietary kind of service network to handle the specific application QoS requirements. This means that such applications generally work well as isolated applications, but it is difficult to integrate them with other applications developed in similar ways. Applications developed for the IP environment, or the Internet, have mainly been based on established standards supporting extensive integration of different applications. The data communication, or the Internet, community has so far not been able to successfully handle real-time communication services in a commercial scale. However, with the introduction of 3G networks (3GPP networks) which may be fixed as well as mobile, telecommunication and data communication services and applications will be mixed, higher and lower bit rates will be mixed as well as real-time and non-real-time traffic will be mixed. 3GPP is the 3rd generation Partnership Project. Standardization work is going on within 3GPP relating to GPRS/UMTS networks and in IETF (Internet Engineering Task Force) and also by means of additional concepts and mechanisms that are developed, to put the mobile Internet into practice.
Routers in the Internet are low-cost equipment as compared to the equipment that has been used traditionally for the international telephony communications network. With the introduction of the mobile Internet, a new generation of equipment will be required. Such equipment will have a lot in common with the conventional Internet equipment, such as routers, but additional requirements are imposed to handle the mobility functionality. One such requirement relates to the capability of handling specific mobile Internet protocols. A particular example of such a requirement, for the GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunication System), is the GPRS Tunneling Protocol (GTP). With the Release 99 and Release 00 of the 3GPP (GPRS/UMTS) standard advanced mechanisms relating to the handling of real-time traffic are also introduced. The 3GPP standard 3G TS 23.107, “QoS Concept and Architecture”, deals with some basic mechanisms in this respect.
Also within the Internet community, e.g. IETF, an intensive work is going on aiming at standardizing mechanisms for handling real-time traffic and multimedia traffic. One very important issue in this respect deals with how a limited bandwidth should be shared between the numerous applications connected to the Internet. The applications and the protocols they use do not always share the bandwidth in a fair way, or do not even try to share the bandwidth in a fair way. One example of that is given by the UDP protocol (User Datagram Protocol) and the TCP (Transmission Control Protocol). The TCP protocol implements built in flow control mechanisms but the UDP does not comprise any flow control mechanisms at all. The fair sharing of bandwidth is moreover complicated due to the fact that many applications are very bursty by nature, such as for example web-applications. Thus, even if the number of users is very large, the total traffic is not leveled (statistical multiplexing) as it is within the normal telecommunication networks. This contributes in making network dimensioning difficult. Moreover the availability of services to the end user will be unreliable. One of the main issues within real-time and multimedia networks is concerned with controlling the IP Packet flow. Several different queueing techniques are known which deal with flow control. Examples of known queueing techniques are Priority Queueing, Class-Based Queueing and Weighted Fair Queueing. The Differential Services (DiffServ) architecture (IN) and Admission Control techniques are also important techniques within the area of controlling flows.
However, all these known techniques normally operate on aggregates of flows of IP packets. The main reason therefore is that, if they were to operate on a per-flow manner, they simply would not scale to provide the desired performance in high-volume, high-speed environments. As an example, Weighted Fair Queueing (WFQ) used in a DiffServ environment is often limited to the six classes defined in RFC 2597 and RFC 2598 (Request For Comment, Network Working Group, Internet Society 1999), which documents herewith are incorporated herein by reference.
WFQ scheduling of only six aggregated flows can be realized without significant computational overhead.
It is however a problem, for example in a mobile Internet environment, that controlling flows on an aggregated level is not sufficient. One reason therefore is that some link resources may be very scarce, limited and therefore expensive. It is also complicated if on the path from for example a packet data network to an end user, the traffic resources differ a lot, i.e. the available bandwidth may differ a lot from one link to another. It is also a disadvantage that for example an operator of a mobile communication system is not able to offer different service levels to subscribers. Therefore Traffic Conditioning on max bit rate per individual flow is included in the QoS architecture of for example UMTS. In UMTS terminology, a flow is defined as one GTP tunnel or one PDP Context (secondary or not), cf. for example 3GPP, 3GTS 23.060 V3.4.0 (2000-07) for description of protocols and terminology which herewith is incorporated herein by reference. However, this is not supported by the known queueing techniques.